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Substructure Type Systems 


David Walker 


Advanced type systems make it possible to restrict access to data structures 
and to limit the use of newly-defined operations. Oftentimes, this sort of 
access control is achieved through the definition of new abstract types under 
control of a particular module. For example, consider the following simplified 
file system interface. 


type file 


val open 
val read 
val append 
val write 
val close 


string — file option 
file — string * file 
file * string — file 
file * string — file 
file — unit 


By declaring that the type f i 1 e is abstract, the implementer of the module 
can maintain strict control over the representation of files. A client has no way 
to accidentally (or maliciously) alter any of the file’s representation invariants. 
Consequently, the implementer may assume that the invariants that he or 
she establishes upon opening a file hold before any read, append, wri te or 
close. 

While abstract types are a powerful means of controlling the structure of 
data, they are not sufficient to limit the ordering and number of uses of func¬ 
tions in an interface. Try as we might, there is no (static) way to prevent a 
file from being read after it has been closed. Likewise, we cannot stop a client 
from closing a file twice or forgetting to close a file. 

This chapter introduces substructure type systems, which augment stan¬ 
dard type abstraction mechanisms with the ability to control the number and 
order of uses of a data structure or operation. Substructural type systems are 
particularly useful for constraining interfaces that provide access to system 
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resources such as files, locks and memory. Each of these resources undergoes 
a series of changes of state throughout its hfetime. Files, as we have seen, may 
be open or closed; locks may be held or not; and memory may be allocated or 
deallocated. Substructural type systems provide sound static mechanisms for 
keeping track of just these sorts of state changes and preventing operations 
on objects in an invalid state. 

The bulk of this chapter will focus on appheations of substructural type 
systems to the control of memory resources. Memory is a pervasive resource 
that must be managed carefully in any programming system so it makes an 
excellent target of study. However, the general principles that we estabhsh 
can be applied to other sorts of resources as well. 

1.1 Structural Proper tie s 

Most of the type systems in this book allow unrestricted use of variables in the 
type checking context. For instance, each variable may be used once, twice, 
three times, or not at all. A precise analysis of the properties of such variables 
will suggest a whole new collection of type systems. 

To begin our exploration, we will analyze the simply-typed lambda calcu¬ 
lus, which is reviewed in Figure 1-1. In this discussion, we are going to be 
particularly careful when it comes to the form of the type-checking context r. 
We will consider such contexts to be simple hsts of variable-type pairs. The 
operator appends a pair to the end of the list. We also write (Tl, T 2 ) for 
the list that results from appending T 2 onto the end of F|. As usual, we al¬ 
low a given variable to appear at most once in a context and to maintain this 
invariant, we implicitly alpha-convert bound variables before entering them 
into the context. 

We are now in position to consider three basic structural properties sat¬ 
isfied by our simply-typed lambda calculus. The first property, exchange, 
indicates that the order in which we write down variables in the context is 
irrelevant. A corollary of exchange is that if we can type check a term with 
the context T, then we can type check that term with any permutation of the 
variables in r. The second property, weakening, indicates that adding extra, 
unneeded assumptions to the context, does not prevent a term from type 
checking. Finally, the third property, contraction, states that if we can type 
check a term using two identical assumptions (X 2 :Ti and X 3 :Ti) then we can 
check the same term using a single assumption. 

1.1.1 Femma [Exchange]: If Ti, xi :Ti, x 2 :T 2 , r 2 1 - t : T then 

Ti, x 2 :T 2 , xi :Ti, r 2 1 -t : T □ 

1.1.2 Femma [Weakening]: If Ti, r 2 1 - t : T then H, x, :Ti,T 2 - t : T □ 
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Syntax 




Typing 

|rnt : T | 

b ::= 











(T-Var) 


true 


true 

r 3 , x: T, r 2 i- x : T 



false 


false 


(T-BOOL) 

t ::= 



terms: 

Y\-b : Bool 



X 


variable 

r i— ti : Bool T i- t 2 : T 

fht 3 : T 


b 


boolean 

r i-if ti then t 2 else t3 : T 


if t then t else t 

conditional 


(T-If) 


Ax:T.t 


abstraction 

r,x:Ti h t 2 : T 2 
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application 

T i- Ax :Ti .t 2 : Ti — T 2 

(T-Abs) 

T ::= 



types: 




Bool 


booleans 

F i- ti : Tii—T i 2 F i— t 2 : 

: Tn 

- (T-App) 


T-T 


type of functions 

r i- ti t 2 : Ti 2 


T ::= 



contexts: 




0 


empty context 




T, x:T 

term 

variable binding 




i_i 


Figure 1-1: Simply-typed lambda calculus with booleans 


1.1.3 Lemma [Contraction]: If Fl, x 2 :Ti, x 3 :Ti, r 2 i- t : T 2 then 

r 1 ,x 1 :Ti,r 2 h- [x 2 ~xi][x 3 -x 3 ]t : T 2 □ 

1.1.4 Exercise [Recommended, ★]: Prove that exchange, weakening and contrac¬ 
tion lemmas hold for the simply-typed lambda calculus. . |§5 

A substructural type system is any type system that is designed so that one 
or more of the structural properties do not hold. Different substructural type 
systems arise when different properties are withheld. 

• Linear type systems ensure that every variable is used exactly once by 
allowing exchange but not weakening or contraction. 

• Affine type systems ensure that every variable is used at most once by 
allowing exchange and weakening, but not contraction. 

• Relevant type systems ensure that every variable is used at least once by 
allowing exchange and contraction, but not weakening. 

• Ordered type systems ensure that every variable is used exactly once and 
in the order in which it is introduced. Ordered type systems do not allow 
any of the structural properties. 
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The picture below can serve as a mnemonic for the relationship between 
these systems. The system at the bottom of the diagram (the ordered type sys¬ 
tem) admits no structural properties. As we proceed upwards in the diagram, 
we add structural properties: E stands for exchange; W stands for weakening; 
and C stands for contraction. It might be possible to define type systems con¬ 
taining other combinations of structural properties, such as contraction only 
or weakening only, but so far researchers have not found applications for 
such combinations. Consequently, we have excluded them from the diagram. 


unrestricted (E,W,C) 



linear (E) 


ordered (none) 


The diagram can be realized as a relation between the systems. We say system 
qi is more restrictive than system t \2 and write qi ^q 2 when system qi exhibits 
fewer structural rules than system q 2 . Figure 1-2 specifies the relation, which 
we will find useful in the coming sections of this chapter. 

1.2 A Linear Type System 

In order to safely deallocate data, we need to know that the data we deallo¬ 
cate is never used in the future. Unfortunately, we cannot, in general, deduce 
whether data will be used after execution passes a certain program point: The 
problem is clearly undecidable. However, there are a number of sound, but 
useful approximate solutions. One such solution may be implemented using 
a linear type system. Linear type systems ensure that objects are used exactly 
once, so it is completely obvious that after the use of an object, it may be 
safely deallocated. 



1.2 A Linear Type System 


ord 

Tin 

rel 

aff 

un 


system: 

ordered 

linear 

relevant 

affine 

unrestricted 


ord ^ Tin 
line rel 
line aff 
rel ^ un 
aff ^ un 

q — q 

qi != q 2 q2 £ q3 

qi ■= q3 


Figure 1-2: A relation between substructural type systems 


(Q-OrdLin) 

(Q-LinRel) 

(Q-LinAff) 

(Q-RelUn) 

(Q-AffUn) 

(Q-Reflex) 

(Q-Trans) 


Syntax 

Figure 1-3 presents the syntax of our linear language, which is an extension 
of the simply-typed lambda calculus. The main addition to be aware of, at 
this point, are the type qualifiers q that annotate the introduction forms for 
all data structures. The linear qualifier (1 i n) indicates that the data structure 
in question will be used (i.e., appear in the appropriate elimination form) ex¬ 
actly once in the program. Operationally, we deallocate these linear values 
immediately after they are used. The unrestricted qualifier (un) indicates that 
the data structure behaves as in the standard simply-typed lambda calculus. 
In other words, unrestricted data can be used as many times as desired and 
its memory resources will be automatically recycled by some extra-linguistic 
mechanism (a conventional garbage collector). 

Apart from the qualifiers, the only slightly unusual syntactic form is the 
elimination form for pairs. The term spl i t ti as x, y i n t 2 projects the first 
and second components from the pair ti and calls them x and y in t 2 - This 
split operation allows us to extract two components while only counting 
a single use of a pair. Extracting two components using the more conven¬ 
tional projections tt\ ti and tt 2 ti requires two uses of the pair ti. (It is also 
possible, but a bit tricky, to provide the conventional projections.) 

To avoid dealing with an unnecessarily heavy syntax, we adopt a couple 
abbreviations in our examples in this section. First, we omit all unrestricted 
qualifiers and only annotate programs with the linear ones. Second, we freely 
use n-ary tuples (triples, quadruples, unit, etc.) in addition to pairs and also 
allow multi-argument functions. The latter may be defined as single-argument 
functions that take linear pairs (triples, etc) as arguments and immediately 
split them upon entry to the function body. Third, we often use ML-style type 
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Syntax 



q ::= 


qualifiers: 


Tin 

linear 


un 

unrestricted 

b ::= 


booleans: 


true 

true 


fal se 

false 

t ::= 


terms: 


X 

variable 


q b 

boolean 


if t then t else t 

conditional 


q <t,t> 

pair 


split t as x. 

,yint split 

q Ax:T.t 

abstraction 

11 

application 


pretypes: 

Bool 

booleans 

T*T 

pairs 

T-T 

functions 


types: 

q P 

qualified pretype 


contexts: 

0 

empty context 

T, x:T 

term variable binding 


i_i 

Figure 1-3: Linear lambda calculus: Syntax 


declarations, value declarations and let expressions where convenient; they 
all have the obvious meanings. 

Typing 

To ensure that hnear objects are used exactly once, our type system maintains 
two important invariants. 

1. Linear variables are used exactly once along every control-flow path. 

2. Unrestricted data structures may not contain linear data structures. More 
generally, data structures with less restrictive type may not contain data 
structures with more restrictive type. 

To understand why these invariants are useful, consider what could hap¬ 
pen if either invariant is broken. When considering the first invariant, as¬ 
sume we have constructed a function free that uses its argument and then 
deallocates it. Now, if we allow a linear variable (say x) to appear twice, a 
programmer might write <f ree x, free x>, or, shghtly more deviously, 

(Az.Ay.<free z,free y>) x x. 

In either case, the program ends up attempting to use and then free x after it 
has aheady been deallocated, causing the program to crash. 

Now consider the second invariant and suppose we allow a hnear data 
structure (call it x) to appear inside an unrestricted pair (un <x, 3>). We can 
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0=000 

r = h o r 2 


I r = ii o r 2 1 

(M-Empty) 


r, x:un P = (fi, x:unP)o (r 2 , x:un P) 


_ r - r , ° r 2 _ 

r,x:lin P = (ri,x:lin P) or 2 

_ r - El ° r 2 _ 

r, x:lin P = Ti o (r 2 , x:1in P) 


Figure 1-4: Linear lambda calculus: Context splitting 


(M-LinI) 

(M-Lin2) 


get exactly the same effect as above by using the unrestricted data structure 
multiple times: 

let z = un <x,3> in 
split z as xl,_ in 
split z as x2in 
<free xl.free x2> 

Fortunately, our type system ensures that none of these situations can occur. 

We maintain the first invariant through careful context management. When 
type checking terms with two or more subterms, we pass all of the unre¬ 
stricted variables in the context to each subterm. However, we split the linear 
variables between the different subterms to ensure each variable is used ex¬ 
actly once. Figure 1-4 defines a relation, F = Ij o r 2 , which describes how to 
split a single context in a rule conclusion (r) into two contexts (Fl and r 2 ) that 
will be used to type different subterms in a rule premise. 

To check the second invariant, we define the predicate q(T) (and its exten¬ 
sion to contexts q(T)) to express the types T that can appear in a q-qualified 
data structure. These containment rules state that linear data structures can 
hold objects with Unear or unrestricted type, but unrestricted data structures 
can only hold objects with unrestricted type. 

• q (T) if and only if T = q' P and q^q' 

• q (r) if and only if (x: T) e T implies q (T) 

Recall, we have already defined q^q' such that it is reflexive, transitive and 
1 i n^un. 

Now that we have defined the rules for containment and context splitting, 
we are ready for the typing rules proper, which appear in Figure 1-5. Keep in 
mind that these rules are constructed anticipating a call-by-value operational 
semantics. 

It is often the case when designing a type system that the rules for the 
base cases, variables and constants, are hardly worth mentioning. However, 
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Typing 


l ri -* ;T l 


un (n,r 2 ) 

ri,x:T,r 2 HX : T 
un (D 

T i- q b : q Bool 
I'i i— tj : q Bool 
r 2 h- t 2 : T r 2 i- t3 : T 
I'i o r 2 i- i f ti then t 2 el se t3 : T 


(T-Var) 

(T-Bool) 


(T-If) 


Figure 1-5: Linear lambda calculus: Typing 


Fi - ti : Ti r 2 ht 2 : T 2 

q(Ti) q(T 2 ) 

Ti o r 2 i- q <ti ,t 2 > : q (Ti*T 2 ) 

Fi i— ti : q (Ti*T 2 ) 

T 2i x:Ti, y:T 2 I- t 2 : T 
Ti or 2 i- spl itti asx,yint 2 : T 
q(r) T, x:Ti i- t 2 : T 2 
r i- q Ax:Ti .t 2 : q Ti-T 2 
Fl i- ti : q Th-Ti 2 r 2 i- t 2 : Tn 
Fi ° r 2 i- ti t 2 : T i2 


(T-Pair) 


(T-Split) 

(T-Abs) 

(T-App) 


in substructural type systems these cases have a special role in defining the 
nature of the type system, and subtle changes can make all the difference. 
In our linear system, the base cases must ensure that no linear variable is 
discarded without being used. To enforce this invariant in rule (T-Var), we 
explicitly check that Fl and r 2 contain no linear variables using the condition 
un (ri,r 2 ). We make a similar check in rule (T-Bool). Notice also that rule (T- 
Var) is written carefully to allow the variable x to appear anywhere in the 
context, rather than just at the beginning or at the end. 

1.2.1 Exercise [*]: What is the effect of rewriting the variable rule as follows? 
un (F) 

--——— (T-BrokenVar) 

The inductive cases of the typing relation take care to use context splitting 
to partition hnear variables between various subterms. For instance, rule (T- 
If) splits the incoming context into two parts, one of which is used to check 
subterm ti and the other which is used to check both t 2 and t3. As a result, 
a particular hnear variable will occur once in t 2 and once in t3. However, the 
linear object bound to the variable in question will be used (and hence de¬ 
allocated) exactly once at run time since only one of t 2 or t 3 will be executed. 

The rules for creation of pairs and functions make use of the containment 
rules. In each case, the data structure’s qualifier q is used in the premise of 
the typing rule to limit the sorts of objects it may contain. For example, in the 
rule (T-Abs), if the qualifier q is un then the variables in r, which will inhabit 
the function closure, must satisfy un (r). In other words, they must all have 
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unrestricted type. If we omitted this constraint, we could write the follow¬ 
ing badly behaved functions. (For clarity, we have retained the unrestricted 
qualifiers in this example rather than omitting them.) 

type T = un (un booi — Tin booi) 

vai discard = 
lin Ax:Tin booi. 

(lin Af:T.iin true) (un Ay:un bool.x) 

vai duplicate = 
lin Ax:lin bool. 

(lin Af:T.lin <f (un true),f (un true)>)) (un Ay:un bool.x) 

The first function discards a linear argument x without using it and the sec¬ 
ond duplicates a linear argument and returns two copies of it in a pair. Hence, 
in the first case, we fail to deallocate x and in the second case, a subsequent 
function may project both elements of the pair and use x twice, which would 
result in a memory error as x would be deallocated immediately after the first 
use. Fortunately, the containment constraint disallows the linear variable x 
from appearing in the unrestricted function (Ay : bool. x). 

Now that we have defined our type system, we should verify our intended 
structural properties: exchange for all variables, and weakening and contrac¬ 
tion for unrestricted variables. 

1.2.2 Lemma [Exchange]: If Ti, xi :Ti, X2 :T2, T2 i- t : T then 


Ti, X2 :T2, Xi :Ti, T2 i-t : T. 

1.2.3 Lemma [Unrestricted Weakening]: If r i— t : T then 

r, xi: un Pi h t : T. □ 

1.2.4 Lemma [Unrestricted Contraction]: 

If T, X 2 :un Pi, X 3 :un Pi i- t : T 3 then 

r, xi:un Pi F- [x 2 - xi][x 3 ~ *i]t : T 3 . □ 

Proof: The proofs of all three lemmas follow by induction on the structure 
of the appropriate typing derivation. 3 ! M 


Algorithmic Linear Type Checking 

The inference rules provided in the previous subsection give a clear, con¬ 
cise specification of the linearly-typed programs. However, these rules are 
also highly non-deterministic and cannot be implemented directly. The pri¬ 
mary difficulty is that to implement the non-deterministic splitting operation, 
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Algorithmic Typing | r,-„ I— t : T; T out | 

Ti, x: un P, T2 h- x : un P;Tl, x: un P, T2 

(A-UVar) 

Ti, x: 1 in P, T2 i- x : Tin P;Tl, T2 (A-LVar) 
r i— q b : q Bool ;T (A-Bool) 

Ti i- ti : q Bool ;T 2 

r 2 1 - t 2 : t ; r 3 r 2 1 - t 3 : t ; r 3 

r 3 i— if ti then t2 else t 3 : T;r 3 


I'l '• ti : Ti ;I 2 r 2 1- t 2 : T 2 ; r 3 

_ g(Ti) q(T 2 ) _ 

r 3 i- q <ti,t 2 > : q (Ti*T 2 ) ;T 3 


(A-Pair) 


Ti f t, : q CTi*T 2 ) ;r 2 
T2, x:Ti, y:T 2 i- t2 : T;T 3 
Ii i- spl i t ti as x, y i n t2 : 
T;r 3 ^ Cx:Ti,y:T 2 ) 
q=un => Ti =T 2 -r- (x:Ti) 
Ti, x:Ti i- t2 : T 2 ;T2 


(A-Split) 


Ti 1- q Ax:Ti ,t 2 : q Ti-T 2 ;r 2 h- (x:Ti) 

(A-Abs) 

fi h ti : q Tn -Ti2;r 2 12 t 3 : Tn ;I3 


fi 1- ti t2 : T12113 


(A-App) 


Figure 1-6: Linear lambda calculus: Algorithmic type checking 


T = r 3 o y 2 , we must guess how to split an input context r into two parts. For¬ 
tunately, it is relatively straightforward to restructure the type checking rules 
to avoid having to make these guesses. This restructuring leads directly to a 
practical type checking algorithm. 

The central idea is that rather than splitting the context into parts before 
checking a complex expression composed of several subexpressions, we can 
pass the entire context as an input to the first subexpression and have it 
return the unused portion as an output. This output may then be used to 
check the next subexpression, which may also return some unused portions 
of the context as an output, and so on. Figure 1-6 makes these ideas concrete. 
It defines a new algorithmic type checking judgment with the form r,„ h- 
t : T; T 0 „ t , where r in is the input context, some portion of which will be 
consumed during type checking of t, and T out is the output context, which 
will be synthesized alongside the type T. 

There are several key changes in our reformulated system. First, the base 
cases for variables and constants allow any context to pass through the judg¬ 
ment rather than restricting the number of linear variables that appear. In 
order to ensure that linear variables are used, we move these checks to the 
rules where variables are introduced. For instance, consider the rule (A-Split). 
The second premise has the form 

I2, x:Ti, y:T 2 1- t2 : T;T 3 

If Ti and T2 are linear, then they should be used in t2 and should not appear 
in r 3 . Conversely, Ti and T2 are unrestricted, then they will always appear 
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in T3, but we should delete them from the final outgoing context of the rule 
so that the ordinary scoping rules for the variables are enforced. To handle 
both the check that hnear variables do not appear and the removal of unre¬ 
stricted variables, we use a special “context difference” operator (A). Using 
this operator, the final outgoing context of the rule (A-Split) is defined to be 
T3 -f- (x :T| , y:T2). Formally, context difference is defined as follows. 

T h- 0 = r 

ri^r 2 =r 3 (x:i-in p) £ r 3 
Ti + (r 2 ,x:lin P) =r 3 
ri -r- r 2 = T3 T3 = T 4 , x: un P, T5 
ri -T- (r 2 , x:un P) =r 4 ,r 5 

Notice that this operator is undefined when we attempt to take the dif¬ 
ference of two contexts, Ti and r 2 , that contain bindings for the same linear 
variable (x: 1 i n P). If the undefined quotient Ti -r- r 2 were to appear anywhere 
in a typing rule, the rule itself would not be considered defined and could not 
be part of a vahd typing derivation. 

The rule for abstraction (A-Abs) also introduces a variable and hence it also 
uses context difference to manipulate the output context for the rule. Ab¬ 
stractions must also satisfy the appropriate containment conditions. In other 
words, rule (A-Abs) must check that unrestricted functions do not contain 
hnear variables. We perform this last check by verifying that when the func¬ 
tion qualifier is unrestricted, the input and output contexts from checking the 
function body are the same. This equivalence check is sufficient because if a 
hnear variable was used in the body of an unrestricted function (and hence 
captured in the function closure), that hnear variable would not show up in 
the outgoing context. 

It is completely straightforward to check that every rule in our algorithmic 
system is syntax directed and that all our auxiliary functions including con¬ 
text membership tests and context difference are easily computable. Hence, 
we need only show that our algorithmic system is equivalent to the simpler 
and more elegant declarative system specified in the previous section. The 
proof of equivalence can be a broken down into the two standard compo¬ 
nents: soundness and completeness of the algorithmic system with respect to 
the declarative system. However, before we can get to the main results, we 
will need to show that our algorithmic system satisfies some basic structural 
properties of its own. In the following lemmas, we use the notation X(T) and 
T1(T) to refer to the hst of hnear and unrestricted assumptions in T respec¬ 
tively. 



14 


1 Substructuml Type Systems 


1.2.5 Lemma [Algorithmic Monotonicity]: If r i— t : T;r then 'U(J') = ll(T) 

and £(T') s £(T). □ 

1.2.6 Lemma [Algorithmic Exchange]: If Ti, xi:Ti, X2:T2, r 2 i- t : T; r 3 then 

Li, X2 :T2, X] :T|, r 2 i- t : T;T 3 and r 3 is the same as r 3 up to transposition of 
the bindings for x 3 and x 2 . □ 

1.2.7 Lemma [Algorithmic Weakening]: If r i- t : T;T' then r, x:T' t- t : T; 

T', x:T'. □ 

1.2.8 Lemma [Algorithmic Linear Strengthening]: If r, x : 1 i n P i- t : T; 

T', x: 1 i n P then r I- t : T;TC □ 


Each of these lemmas may be proven directly by induction on the initial 
typing derivation. The algorithmic system also satisfies a contraction lemma, 
but since it will not be necessary in the proofs of soundness and complete¬ 
ness, we have not stated it here. 

1.2.9 Theorem [Algorithmic Soundness]: If Ti i- t : T;T 2 and £(T 2 ) = 0 then 
Fj: W t : T. □ 

Proof: As usual, the proof is by induction on the typing derivation. The struc¬ 
tural lemmas we have just proven are required to push through the result, but 
it is mostly straightforward. □ 

1.2.10 Theorem [Algorithmic Completeness]: If r 3 i— t : T then T] i- t : T;T 2 
and X(T 2 ) = 0. □ 

Proof: The proof is by induction on the typing derivation. □ 


Operational Semantics 

To make the memory management properties of our language clear, we will 
evaluate terms in an abstract machine with an explicit store. As indicated in 
Figure 1-7, stores are a sequence of variable-value pairs. We will implicitly 
assume that any variable appears at most once on the left-hand side of a pair 
so the sequence may be treated as a finite partial map. 

A value is a pair of a qualifier together with some data (a prevalue w). For 
the sake of symmetry, we will also assume that all values are stored, even 
base types such as booleans. As a result, both components of any pair will be 
pointers (variables). 

We define the operation of our abstract machine using a context-based, 
small-step semantics. Figure 1-7 defines the computational contexts E, which 
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b 

<x,y> 

Ax:T.t 


0 

S, x- 


prevalues: e 

boolean 
pair 
abstraction 
values: 
qualified prevalue 
stores: 
empty context 
store binding 


Figure 1-7: Linear lambda calculus: Run-time data 


[] 

if Ethen t else t 
q <E,t> 
q <x,E> 

split E as x,y in t 
Et 
x E 


evaluation contexts: 
context hole 
if context 
fst context 
snd context 
split context 
fun context 
arg context 


are terms with a single hole. Contexts define the order of evaluation of terms— 
they specify the places in a term where a computation can occur. In our case, 
evaluation is left-to-right since, for example, there is a context with the form 
E t indicating that we can reduce the term in the function position before re¬ 
ducing the term in the argument position. However, there is no context with 
the form t E. Instead, there is only the more limited context x E, indicating 
that we must reduce the term in the function position to a pointer x before 
proceeding to evaluate the term in the argument position. We use the nota¬ 
tion E [t] to denote the term composed of the context E with its hole plugged 
by the computation t. 

The operational semantics, defined in Figure 1-8, is factored into two re¬ 
lations. The first relation, (S;t) — (S' ;t'), picks out a subcomputation to 
evaluate. The second relation, (S;t) —-p (S';t'), does all the real work. In 
order to avoid creation of two sets of operational rules, one for linear data, 
which is deallocated when used, and one for unrestricted data, which is never 
deallocated, we define an auxiliary function, S ~ x, to manage the differences. 

(S 1 ,x-v,S 2 ) 1 i n x = Si ,$ 2 

S ~ x = S 

Aside from these details, the operational semantics is standard. 

Preservation and Progress 

In order to prove the standard safety properties for our language, we need to 
be able to show that programs are well-formed after each step in evaluation. 
Hence, we will define typing rules for our abstract machine. Since these typing 
rules are only necessary for the proof of soundness, and have no place in an 
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Top-level Evaluation | (S;t) — (S' ;t') | 
CS;t) —(S;t') 

CS,E[t])-CS;E[t']) ,E ' CTXI> 

Evaluation | (S;t) (S' ;t') | 

P (S, X ~ 


(S;q b) —>p (S, x — q b;x) 
S(x) = q true 


(E-BOOL) 


(S; i f x then ti el se t 2 ) - 


B CS~ 


c;ti) 

(E-lFl) 


S(x) = q false 


(S;if x then ti else t 2 ) -^p (S ~ x;t 2 ) 

(E-If2) 

(S;q <y,z>) — p (S, x — q <y,z>;x) (E-Pair) 
S(x) =q <yi,zi> 

—-—-—7- (E-Split) 

(S; spl 1 1 x as y, z i n t) — 

(S ~ x; [y >— yi ][z v- Zl ]t) 

(S;q Ay:T.t) -~p (S,x-q Ay:T.t;x) 

(E-Fun) 

S(Xi) = q Ay:T.t 


CS;xi x 2 ) -~p (S ~ xi ;[y ~ x 2 ]t) 


(E-App) 


Figure 1-8: Linear lambda calculus: Operational semantics 


implementation, we will extend the declarative typing rules rather than the 
algorithmic typing rules. 

Figure 1-9 presents the machine typing rules in terms of two judgments, 
one for stores and the other for programs. The store typing rules generate a 
context that describes the available bindings in the store. The program typ¬ 
ing rule uses the generated bindings to check the expression that will be 
executed. 

With this new machinery in hand, we are able to prove the standard progress 
and preservation theorems. 

1.2.11 Theorem [Preservation]: If h- (S;t) and (S;t) — (S';t') then 

h(S';t'). □ 

1.2.12 Theorem [Progress]: If f- (S;t) then (S;t) — (S';t') or t is a value. □ 

1.2.13 Exercise [Recommended, *]: You will need a substitution lemma to com¬ 
plete the proof of preservation. Is the following the right one? 

Conjecture: Let T 3 = Ti o I 2 . If Ij, x:T h ti : Ti and T 2 1 - t : T then 
r3 H [X - t]t! : Ti. □ 

1.2.14 Exercise [★★★, *►}: Prove progress and preservation using TAPL, Chapters 9 

and 13, as an approximate guide. □ 
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Store Typing 

\- 0 : 0 

i- S : Ti o l 2 I\ f- 1 i n w : T 
i-SjX 1 —-linwi^jXiT 


^ S;r l 

(T-EmptyS) 

(T-NextlinS) 


i- S : Ti o y 2 El i- un w : T 
i-S,x«unw : T2,x:T 


(T-NextunS) 


Program Typing 

h- S : r r i— t : T 
h (S;t) 


(t-prog) 


I_I 

Figure 1-9: Linear lambda calculus: Program typing 


1.3 Extensions and Variations 

Most features found in modern programming languages can be defined to 
interoperate successfully with Unear type systems, although some are trickier 
than others. In this section, we will consider a variety of practical extensions 
to our simple Unear lambda calculus. 

Sums and Recursive Types 

Complex data structures, such as the recursive data types found in ML-Uke 
languages, pose little problem for linear languages. To demonstrate the cen¬ 
tral ideas involved, we extend the syntax for the linear lambda calculus with 
the standard introduction and elimination forms for sums and recursive types. 
The details are presented in Figure 1-10. 

Values with sum type are introduced by injections q in1 P t or q inr P t, 
where P is T1+T2, the resulting pretype of the term. In the first instance, the 
underlying term t must have type Ti, and in the second instance, the under¬ 
lying term t must have type T2. The qualifier q indicates the hnearity of the 
argument in exactly the same way as for pairs. The case expression will exe¬ 
cute its first branch if its primary argument is a left injection and its second 
branch if its primary argument is a right injection. We assume that + binds 
more tightly that —■ but less tightly than *. 

Recursive types are introduced with a rol 1 p t expression, where P is the 
recursive pretype the expression will assume. Unlike all the other introduc¬ 
tion forms, roll expressions are not annotated with a qualifier. Instead, they 
take on the qualifier of the underlying expression t. The reason for this dis¬ 
tinction is that we will treat this introduction form as a typing coercion that 
has no real operational effect. Unlike functions, pairs or sums, recursive data 
types have no data of their own and therefore do not need a separate quali¬ 
fier to control their allocation behavior. To simplify the notational overhead 
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P 


terms: 
as before 

qinlpt leftinj. 

qinrpt right inj. 

case t (ini x => t | i nr y => t) case 
rollp t roll into rec type 

unrol 1 t unroll from rec type 

fun f (x:Ti) :T2 .t recursive fun 
pretypes: 

... as before 

a pretype variables 

T1+T2 sum types 

reca.T recursive types 


Typing [T 

f 1- t : Ti q(Ti) q(T 2 ) 

r 1- q i n 1 Tl +T 2 t : q (Ti+T 2 ) 
f 1- t : T 2 qCTi) q(T 2 ) 

r 1- q inr Tl+ T z t : q (Ti+T 2 ) 

I'i 1— t : q (T1+T2) 

f2, x:T] (- ti : T f2, y:T2 1- t2 


(T-Inl) 

(T-Inr) 


Ti o T2 1- case t (i nl x => ti | i nr y => t2) : T 
(T-Case) 


fnt : [a~ P]q Pi 

f 1- rol 1 P t 


P = rec a.q Pi 

T^P 

(T-Roll) 


r 1- t : P P = rec a.q Pi 
T 1- unroll t : [a — P]q Pi 
un (f) f, f :unTi-T 2 , x:Ti h 


(T-Unroll) 
t : T 2 


T 1- fun f(x:Ti):T2.t : un Ti^T 2 

(T-TFUN) 


1_1 

Figure 1-10: Linear lambda calculus: Sums and recursive types 


of sums and recursive types, we will normally omit the typing annotations on 
their introduction forms in our examples. 

In order to write computations that process recursive types, we add recur¬ 
sive function declarations to our language as well. Since the free variables in 
a recursive function closure will be used on each recursive invocation of the 
function, we cannot allow the closure to contain linear variables. Hence, all 
recursive functions are unrestricted data structures. 

A simple but useful data structure is the linear list of Ts: 

type T Hist = rec a. Tin (unit + Tin (T * Tin a)) 

Here, the entire spine (aside from the terminating value of unit type) is linear 
while the underlying T objects may be linear or unrestricted. To create a fully 
unrestricted list, we simply omit the Unear qualifiers on the sum and pairs 
that make up the spine of the list: 

type T list = rec a.unit + T * a 
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After defining the linear lists, the memory conscious programmer can write 
many familiar list-processing functions in a minimal amount of space. For 
example, here is how we map an unrestricted function across a linear list. 
Remember, multi-argument functions are abbreviations for functions that ac¬ 
cept linear pairs as arguments. 

fun nil(_:unit) : T 2 iiist = 
roll (Tin ini ()) 

fun cons(hd:T 2 , ti :T 2 Hist) : T 2 iiist = 
roll Cl in inr (lin <hd,tl>)) 

fun map(f:Ti— T 2 , xs:Ti Iiist) : T 2 Hist = 
case unroll xs ( 
ini _ => nil() 

| inr xs # 

split xs as hd,tl in 
cons(f hd,map lin <f,tl>)) 

In this implementation of map, we can observe that on each iteration of the 
loop, it is possible to reuse the space deallocated by spl i t or case operations 
for the allocation operations that follow in the body of the function (inside 
the calls to ni 1 and cons). 

Hence, at first glance, it appears that map will execute with only a constant 
space overhead. Unfortunately, however, there are some hidden costs as map 
executes. A typical implementation will store local variables and temporaries 
on the stack before making a recursive call. In this case, the result of f hd will 
be stored on the stack while map iterates down the list. Consequently, rather 
than having a constant space overhead, our map implementation will have an 
O(n) overhead, where n is the length of the list. This is not too bad, but we 
can do better. 

In order to do better, we need to avoid implicit stack allocation of data 
each time we iterate through the body of a recursive function. Fortunately, 
many functional programming languages guarantee that if the last operation 
in a function is itself a function call then the language implementation will 
deallocate the current stack frame before calling the new function. We name 
such function calls tail calls and we say that any language implementation 
that guarantees that the current stack frame will be deallocated before a tail 
call is tail-call optimizing. 

Assuming that our language is tail-call optimizing, we can now rewrite map 
so that it executes with only a constant space overhead. The main trick in¬ 
volved is that we will explicitly keep track of both the part of the input list we 
have yet to process and the ouput list that we have already processed. The 




20 


1 Substructural Type Systems 


output list will wind up in reverse order, so we will reverse it at the end. Both 
of the loops in the code, mapRev and reverse are tail-recursive functions. 
That is, they end in a tail call and have a space-efficient implementation. 

fun map(f:Ti^T 2 , input:Ti Hist) : T 2 Hist = 
reverse(mapRev(f,input.nii()),nii()) 

and mapRev(f:Ti—T 2 , 

input:Ti Hist, 
output:T 2 Hist) : T 2 Hist = 
case unroll input ( 
ini _ => output 

| inr xs => 

split xs as hd.tl in 

mapRev (f,tl,cons(f hd,output))) 

and reverse(input:T 2 Hist, output:T 2 Hist) 
case unroll input ( 
ini _ => output 

| inr xs => 

split xs as hd,tl in 
reverse(tl,cons(hd,output))) 

This link reversal algorithm is a well-known way of traversing a list in 
constant space. It is just one of a class of algorithms developed well before 
the invention of linear types. A similar algorithm was invented by Deutsch, 
Schorr, and Waite for traversing trees and graphs in constant space. Such con¬ 
stant space traversals are essential parts of mark-sweep garbage collectors— 
at garbage collection time there is no extra space for a stack so any traversal 
of the heap must be done in constant space. 

1.3.1 Exercise [*★*]: Define a recursive type that describes linear binary trees 
that hold data of type T in their internal nodes (nothing at the leaves). Write 
a constant-space function treeMap that produces an identically-shaped tree 
on output as it was given on input, modulo the action of the function f that 
is applied to each element of the tree. Feel free to use reasonable extensions 
to our linear lambda calculus including mutually recursive functions, n-ary 
tuples and n-ary sums. □ 

Polymorphism 

Parametric polymorphism is a crucial feature of almost any functional lan¬ 
guage, and our linear lambda calculus is no exception. The main function of 
polymorphism in our setting is to support two different sorts of code reuse. 
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1. Reuse of code to perform the same algorithm, but on data with different 
shapes. 

2. Reuse of code to perform the same algorithm, but on data governed by 
different memory management strategies. 

To support the first kind of polymorphism, we will allow quantification 
over pretypes. To support the second kind of polymorphism, we will allow 
quantification over qualifiers. A good example of both sorts of polymorphism 
arises in the definition of a polymorphic map function. In the code below, we 
use a and b to range over pretype variables as we did in the previous section, 
and p to range over qualifier variables. 

type (pi,p 2 ,a) list = 

rec a.pi (unit + pi (p 2 a * (pi,p 2 ,a) list)) 


map : 

Va,b. 

Vp a ,Pb. 

lin CCP« a - p b b)*(lin,p fl ,a) list)-(lin,p„,b) list 

The type definition in the first hne defines hsts in terms of three parameters. 
The first parameter, pi, gives the usage pattern (linear or unrestricted) for the 
spine of the list, while the second parameter gives the usage pattern for the 
elements of the list. The third parameter is a pretype parameter, which gives 
the (pre)type of the elements of list. The map function is polymorphic in the 
argument (a) and result (b) element types of the list. It is also polymorphic 
(via parameters p a and pb) in the way those elements are used. Overall, the 
function maps lists with linear spines to lists with hnear spines. 

Developing a system for polymorphic, linear type inference is a challenging 
research topic, beyond the scope of this book, so we will assume that, unlike 
in ML, polymorphic functions are introduced exphcitly using the syntax Aa. t 
or Ap. t. Here, a and p are the type parameters to a function with body t. The 
body does not need to be a value, hke in ML, since we will run the polymorphic 
function every time a pretype or qualifier is passed to the function as an 
argument. The syntax t' [P] or t' [q] applies the function t' to its pretype 
or qualifier argument. Figure 1-11 summarizes the syntactic extensions to the 
language. 

Before we get to writing the map function, we will take a look at the poly¬ 
morphic constructor functions for hnear lists. These functions will take a 
pretype parameter and two qualifier parameters, just hke the type definition 
for hsts. 
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q ::= 

qualifiers: 

q Ap.t 

qualifier abstraction 


as before 

t [q] 

qualifier application 

P 

polymorphic qualifier 

P ::= 

pretypes: 

t ::= 

terms: 


as before 


as before 

Va.T 

pretype polymorphism 

q Aa.t 
t [P] 

i_ 

pretype abstraction 
pretype application 

Vp.T 

qualifier polymorphism 

_i 


Figure 1-11: Linear lambda calculus: Polymorphism syntax 


val nil : Va,p 2 . (lin,p 2 ,a) list = 

Aa,p 2 .roll Clin ini ()) 

val list : 

Va,p 2 .lin (p 2 a * (lin,p 2 ,a) list)-(lin,p 2 ,a) list = 

Aa,p 2 . 

Acell : lin (p 2 a * (lin,p 2 ,a) list), 
roll (lin inr (lin cell)) 

Now our most polymorphic map function may be written as follows. 

val map = 

Aa,b. Ap fl ,pi,. 

fun aux(f:(p fl a — p b b), 

xs: (lin,p fl ,a) list)) : (lin,ph,b) list = 
case unroll xs ( 

ini _ => nil [b,p to ] () 

| inr xs => split xs as hd,tl in 

cons [b,Pb] (p b <f hd.map (lin <f,tl>)>)) 

In order to ensure that our type system remains sound in the presence 
of pretype polymorphism, we add the obvious typing rules, but change very 
little else. However, adding qualifier polymorphism, as we have done, is a 
little more involved. Before arriving at the typing rules themselves, we need 
to adapt some of our basic definitions to account for abstract qualifiers that 
may either be linear or unrestricted. 

First, we need to ensure that we propagate contexts containing abstract 
qualifiers safely through the other typing rules in the system. Most impor¬ 
tantly, we add additional cases to the context manipulation rules defined in 
the previous section. We need to ensure that linear hypotheses are not du¬ 
plicated and therefore we cannot risk duplicating unknown qualifiers, which 
might turn out to be linear. Figure 1-12 specifies the details. 
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r,x: P p= (ri,x:pP)or 2 


I r = ii o r 2 1 

(M-AbsI) 


r, x:p P = Ti o (r 2 , x:p P) 


Figure 1-12: Linear context manipulation rules 


A ::= 

0 

A, a 
A, p 

Typing 

q(D A, a;T i- t : T 
A;T i- q Aa.t : q Va.T 


type contexts: 
empty 
pretype var. 
qualifier var. 
|A;Tht : T| 

(T-PAbs) 


A;T h t : q Va.T FV(P) ^ A 
A;T ht[P] : [a — P]T 
q(r) A, p;T I- t : T 
A;T i- q Ap.t : q Vp.T 
A;Tht:qi Vp.T FV(q) G A 
A;Tht [q] : [p ~ q]T 


Figure 1-13: Linear lambda calculus: Polymorphic typing 


(T-PApp) 

(T-QAbs) 

(T-QApp) 


Second, we need to conservatively extend the relation on type qualifiers 
qi^q 2 so that it is sound in the presence of qualifier polymorphism. Since 
the linear qualifier is the least qualifier in the current system, the following 
rule should hold. 

1 i n m p (Q-LinP) 

Likewise, since un is the greatest qualifier in the system, we can be sure the 
following rule is sound. 

p E un (Q-PUn) 

Aside from these rules, we will only be able to infer that an abstract qual¬ 
ifier p is related to itself via the general reflexivity rule. Consequently, lin¬ 
ear data structures can contain abstract ones; abstract data structures can 
contain unrestricted data structures; and data structure with qualifier p can 
contain other data with qualifier p. 

In order to define the typing rules for the polymorphic linear lambda cal¬ 
culus proper, we need to change the judgment form to keep track of the type 
variables that are allowed to appear free in a term. The new judgment uses 
the type context A for this purpose. The typing rules for the introduction and 
elimination forms for each sort of polymorphism are fairly straightforward 
now and are presented in Figure 1-13. 
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The typing rules for the other constructs we have seen are almost un¬ 
changed. One relatively minor alteration is that the incoming type context 
A will be propagated through the rules to account for the free type variables. 
Unlike term variables, type variables can always be used in an unrestricted 
fashion; it is difficult to understand what it would mean to restrict the use 
of a type variable to one place in a type or term. Consequently, all parts of A 
are propagated from the conclusion of any rule to all premises. We also need 
the occasional side condition to check that whenever a programmer writes 
down a type, its free variables are contained in the current type context A. 
For instance the rules for function abstraction and application will now be 
written as follows. 

q(r) FV(Ti)<=A A;T, x:Ti i-t 2 : 

- (T-Abs) 

A;r i— q Ax:Ti . t 2 : q Ti^T 2 


A;Ti i- ti : q Ti—T 2 A;T 2 i-t 2 :Ti 
A;Ti o r 2 i- ti t 2 : T 2 


(T-App) 


The most important way to test our system for faults is to prove the type 
substitution lemma. In particular, the proof will demonstrate that we have 
made safe assumptions about how abstract type qualifiers may be used. 


1.3.2 Lemma [Type Substitution]: 

1. If A, p;T i- t : T and FV(q) e A then A; [p — q]r i- [p >- q]t : [p •-* q]T 

2. If A, a; T \- t : T and FV( P) e A then A; [a — P]r i- [a — P]t : [a — P]T n 


1.3.3 Exercise [★]: Sketch the proof of the type substitution lemma. What struc¬ 
tural rule(s) do you need to carry out the proof? □ 

Operationally, we will choose to implement polymorphic instantiation us¬ 
ing substitution. As a result, our operational semantics changes very little. 
We only need to specify the new computational contexts and to add the eval¬ 
uation rules for polymorphic functions and application as in Figure 1-14. 


Arrays 

Arrays pose a special problem for linearly typed languages. If we try to pro¬ 
vide an operation fetches an element from an array in the usual way, perhaps 
using an array index expression a[i ], we would need to reflect the fact that 
the i th element (and only the i th element) of the array had been “used.” How¬ 
ever, there is no simple way to reflect this change in the type of an array as the 
usual form of array types (array(T)) provides no mechanism to distinguish 
between the properties of different elements of the array. 
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E ::= evaluation contexts: 

E [P] pretype app context 

E [q] qualifier app context 

(S; q Aa. t) —p (S, x — q Aa. t; x) (E-PFun) 


S(x) = q Aa.t 

(S;x [P]) —* (S ~ x;[a ~ P]t) 
(S; q Ap. t) —(S,x« qAp.t;x) 
S(x) = q Ap.t 

(S;x [qi]) — p (S ~ x;[p ~ qi]t) 


Figure 1-14: Linear lambda calculus: Polymorphic operational semantics 


(E-PApp) 

(E-QFun) 

(E-QApp) 


We dodged this problem when we constructed our tuple operations by 
defining a pattern matching construct that simultaneously extracted all of 
the elements of a tuple. Unfortunately, we cannot follow the same path for 
arrays because in modern languages like Java and ML, the length of an array 
(and therefore the size of the pattern) is unknown at compile time. 

Another non-solution to the problem is to add a special built-in iterator 
to process all the elements in an array at once. However, this last prevents 
programmers from using arrays as efficient, constant-time, random-access 
data structures; they might as well use lists instead. 

One way out of this jam is to design the central array access operations so 
that, unlike the ordinary “get” and “set” operations, they preserve the number 
of pointers to the array and the number of pointers to each of its elements. 
We avoid our problem because there is no change to the array data structure 
that needs to be reflected in the type system. Using this idea, we will be able 
to allow programmers to define linear arrays that can hold a collection of 
arbitrarily many linear objects. Moreover, programmers will be able to access 
any of these linear objects, one at a time, using a convenient, constant-time, 
random-access mechanism. 

So, what are the magic pointer-preserving array access operations? Actu¬ 
ally, we need only one: a swap operation with the form swap (a[i] ,t). The 
swap replaces the i th element of the array a (call it t') with t and returns a 
(Unear) pair containing the new array and t'. Notice the number of pointers 
to t and t' does not change during the operation. If there was one pointer 
to t (as an argument to swap) before the caU, then there is one pointer to t 
afterward (from within the array a) and vice versa for t'. If, in addition, ah of 
the elements of a had one pointer to them before the swap, then they wiU all 
have one pointer to them after the swap as well. Consequently, we wiU find 
it easy to type the swap operation, even when it works over Unear arrays of 
Unear objects. 
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In addition to swap, we provide functions to allocate an array given its list 
of elements (array), to determine array length (length) and to deallocate 
arrays (free). The last operation is somewhat unusual in that it takes two 
arguments a and f, where a is an array of type Tin array(T) and f is a 
function with type T^unit that is run on each element of T. The function 
may be thought of as a finalizer for the elements; it may be used to deallocate 
any linear components of the array elements, thereby preserving the single 
pointer property. 

Our definition of arrays is compatible with the polymorphic system from 
the previous subsection, but for simplicity, we formalize it in the context of 
the simply-typed lambda calculus (see Figure 1-15). 

1.3.4 Exercise [Recommended, *]: The typing rule for array allocation (T-Array) 

contains the standard containment check to ensure that unrestricted arrays 
cannot contain linear objects. What kinds of errors can occur if this check is 
omitted? □ 

1.3.5 Exercise [★*, -*■]: With the presence of mutable data structures, it is possible 

to create cycles in the store. How should we modify the store typing rules to 
take this into account? □ 

The swap and free functions are relatively low-level operations. Fortu¬ 
nately, it is easy to build more convenient, higher-level abstractions out of 
them. For instance, the following code defines some simple functions for ma¬ 
nipulating linear matricies of unrestricted integers. 

type iArray = Tin array(int) 
type matrix = Tin array(iArray) 

fun dummy(x:unit):iArray = Tin array!) 

fun freeETem(x:int):unit = O 

fun freeArray(a:iArray):unit = free(a,freeETem) 

fun freeMatrix(m:matrix):unit = free(m,freeArray) 

fun get(a:matrix,i:int,j:int):lin (matrix * int) = 
split swap(a[i],dummy()) as a,b in 
split swap(b[j],0) as b,k in 

split swap(b[j],k) as b,_ in 

split swap(a[i],b) as a,junk in 

freeArray(junk); 

Tin <a,k> 
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p 

::= 

pretypes: 



as before 


arrayCT) 

array pretypes 

t 

::= 

terms: 



as before 


q arrayCt, ... ,t) 

array creation 


swapCt[t],t) 

swap 


TengthCt) 

length 


freeCt.t) 

deallocate 

w 

::= 

prevalues: 



as before 


array[n,x,... ,x] 

array 

E 

::= evaluation contexts: 



as before 


q arrayCv,... ,v,E,t, 

_t) 

array context 


swapCECt),t) 

swap context 


swapCvCE),t) 

swap context 


swapCvCv),E) 

swap context 


TengthCE) 

length context 


freeCE.t) 

free context 


freeCv,E) 

free context 


Typing |r I- t : T| 

q(T) r i— t f : T (for 1 <i <n) 


r i— q arrayCti, ... ,t„) : q array(T) 

(T-Array) 


I" i- ti : qi array(Ti) 
r i- t 2 : q 2 int r i- t 3 : Ti 
T i- swapCti [t 2 ] ,t 3 ) : 

Tin (qi array(Ti) * Ti) 


(T-Swap) 


T i- t : q arrayCT) 

T i- length(t) : Tin Cq array(T) * int) 

(T-Length) 

I'' t| : q array(T) Y \- t 2 : T — unit 


T i- free(ti ,t 2 ) : unit 

(T-Free) 

Evaluation | (S;t) — p (S' ;t') | 

(S;q array(x 0 , ...,x„_i)) —^ 

CCS, x - q array[n,x 0 , ... ,x„_i];x) 

(E-Array) 


SCx,) = q, j 

S = Si, x a — q array[n, ... ,Xj, . ..], S 2 
S' = Si, x a — q array[n, ... ,x e ,...], S 2 
CS; swapCxa [x,] ,x e )) 


CS' ~ x,; T i n <x„, Xj>) 

(E-Swap) 


SCx) = q array[n,x 0 , ...,x„_i] 


CS; T ength Cx) ) —*p CS; T i n <x, un n>) 

(E-Length) 


CS;freeCx a ,x^-)) 

—p CS ~ x a jAppCx^-,x 0 , ... ,x„_i)) 

(E-Free) 


Figure 1-15: Linear lambda calculus: Arrays 


where 
AppCxfi■) 
AppCxf,x 0 ,...) 


0 

Xf XQjAppCX f ,...) 
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fun set(a:matrix,i :int, j :int,e:int) :matrix = 
split swap(a[i],dummy()) as a,b in 
split swap(b[j],e) as b,_ in 
split swap(a[i],b) as a,junk in 
freeArray(junk); 


1.3.6 Exercise [*★, +*]: Use the functions provided above to write matrix-matrix 
multiply. Your multiply function should return an integer and deallocate both 
arrays in the process. Use any standard integer operations necessary. □ 

In the examples above, we needed some sort of dummy value to swap into 
an array to replace the value we wanted to extract. For integers and arrays 
it was easy to come up with one. However, when dealing with polymorphic 
or abstract types, it may not be possible to conjure up a value of the right 
type. Consequently, rather than manipulating arrays with type q array(a) 
for some abstract type a, we may need to manipulate arrays of options with 
type q arrayCa + unit). In this case, when we need to read out a value, we 
always have another value (inr ()) to swap in in its place. Normally such 
operations are called destructive reads', they are a common way to preserve 
the single pointer property when managing complex structured data. 

Reference Counting 

Array swaps and destructive reads are dynamic techniques that can help over¬ 
come a lack of compile-time knowledge about the number of uses of a par¬ 
ticular object. Reference counting is another dynamic technique that serves a 
similar purpose. Rather than restricting the number of pointers to an object 
to be exactly one, we can allow any number of pointers to the object and keep 
track of that number dynamically. Only when the last reference is used will 
the object be deallocated. 

There are various ways to integrate reference counts into the current sys¬ 
tem. Here, we choose the simplest, which is to add a new qualifier rc for 
reference-counted data structures, and operations that allow the programmer 
to explicitly increment (i nc) and decrement (dec) the counts (see Figure 1-16). 
More specifically, the increment operation takes a pointer argument, incre¬ 
ments the reference count for the object pointed to, and returns two copies 
of the pointer in a (hnear) pair. The decrement operation takes two argu¬ 
ments, a pointer and a function, and works as follows. In the case the object 
pointed to (call it x) has a reference count of 1 before the decrement, the 
function is executed with x as a linear argument. Since the function treats x 
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Syntax 

q ::= 

rc 

qualifiers: 
as before 
ref. count 

Qualifier Relations 

rc ^ un 

lin E rc 

(Q-RCUn) 

(Q-LinRC) 

t ::= 


terms: 

Typing 

l r| -t ; T| 


inc(t) 

dec(t,t) 

as before 

r i— t : rc P 

(t-inc) 

unit 


increment count 

decrement count 

T i- inc(t) : lin (rc P * rc P) 

r i- t! : rc P T i- t2 : 1 i n P - 




T i- dec(ti ,t2) : unit 

(T-Dec) 

Figure 

1-16: Linear lambda calculus: Reference counting syntax and typing 



linearly, it will deallocate x before it completes. In the other case, when x has 
a reference count greater than 1, the reference count is simply decremented 
and the function is not called; uni t is returned as the result of the operation. 

The main typing invariant in this system is that whenever a reference- 
counted variable appears in the static type-checking context, there is one 
dynamic reference count associated with it. Linear typing will ensure the 
number of references to an object is properly preserved. 

The new rc qualifier should be treated in the same manner as the linear 
qualifier when it comes to context splitting. In other words, a reference- 
counted variable should be placed in exactly one of the left-hand context 
or the right-hand context (not both). In terms of containment, the rc quali¬ 
fier sits between unrestricted and linear qualifiers: A reference-counted data 
structure may not be contained in unrestricted data structures and may not 
contain hnear data structures. Figure 1-16 presents the appropriate qualifier 
relation and typing rules for our reference counting additions. 

In order to define the execution behavior of reference-counted data struc¬ 
tures, we will define a new sort of stored value with the form rc(n) w. The 
integer n is the reference count: it keeps track of the number of times the 
value is referenced elsewhere in the store or in the program. 

The operational semantics for the new commands and reference-counted 
pairs and functions are summarized in Figure 1-17. Several new bits of no¬ 
tation show up here to handle the relatively complex computation that must 
go on to increment and decrement reference counts. First, in a slight abuse 
of notation, we allow q to range over static qualifiers un, 1 i n and rc as well 
as dynamic qualifiers un, lin and rc(n). Context will disambiguate the two 
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different sorts of uses. Second, we extend the notation S~x so that q may 
be rc(n) as well as Tin and un. If n is 1 then S rc ~ n) x removes the binding 
x^rc(n) w from S. Otherwise, S rc ~ n) x replaces the binding x~rc(n) w with 
x^rc(n-l) w. Finally, given a store S and a set of variables X, we define the 
function incr(S;X), which produces a new store S' in which the reference 
count associated with any reference-counted variables xeX is increased by 1. 

To understand how the reference counting operational semantics works, 
we will focus on the rules for pairs. Allocation and use of hnear and unre¬ 
stricted pairs stays unchanged from before as in rules (E-Pair’) and (E-Split’). 
Rule (E-PairRC) specifies that allocation of reference-counted pairs is simi¬ 
lar to allocation of other data, except for the fact that the dynamic reference 
count must be initialized to 1. Use of reference-counted pairs is identical to 
use of other kinds of pairs when the reference count is 1: We remove the 
pair from the store via the function S rc ~ ni x as shown in rule and substi¬ 
tute the two components of the pair in the body of the term as shown in 
(E-Split’). When the reference count is greater than 1, rule (E-SplitRC) shows 
there are additional complications. More precisely, if one of the components 
of the pair, say yi, is reference-counted then yi’s reference count must be 
increased by 1 since an additional copy of yi is substituted through the body 
of t. We use the incr function to handle the possible increase. In most re¬ 
spects, the operational rules for reference-counted functions follow the same 
principles as reference-counted pairs. Increment and decrement operations 
are also relatively straightforward. 

In order to state and prove the progress and preservation lemmas for our 
reference-counting language, we must generalize the type system slightly. In 
particular, our typing contexts must be able specify the fact that a particular 
reference should appear exactly n times in the store or current computation. 
Reference-counted values in the store are described by these contexts and 
the context-splitting relation is generalized appropriately. Figure 1-18 sum¬ 
marizes the additional typing rules. 

1.3.7 Exercise [★★★, ■+*]: State and prove progress and preservation lemmas for 
the simply-typed hnear lambda calculus (functions and pairs) with reference 
counting. □ 


1.4 An Ordered Type System 

Just as linear type systems provide a foundation for managing memory allo¬ 
cated on the heap, ordered type systems provide a foundation for managing 
memory allocated on the stack. The central idea is that by controlhng the 
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v ::= 

values: 


as before 

rc(n) w 

ref-counted value 

E ::= 

evaluation contexts: 


as before 

inc(E) 

inc context 

dec(E,t) 

dec context 

dec(x,E) 

dec context 

Evaluation 

| (S;t) — p (S';t') | 


(q G {un,1in}) 

(S;q <y,z>) -^p (S, x ~ q <y,z>;x) 

(E-Pair’) 


(S; rc <y,z>) -^p 
CS, x — rcCl) <y ,z>;x) 


(E-PairRC) 


SCx) = q <yi ,zi> 

(q g {un,1in,rcCl)}) 

CS; spl i t x as y, z i n t) —>p 
CS ~ x;[y ~ yi ||z zi |t) 
SCx) = rcCn) <yi ,zi> (n > 1) 
incrCS;{yi,zi}) = S' 


CS; spl i t x as y, z i n t) — p 
CCS' rc ^ n) x);[y-y' 1 ][z^z' 1 ]t) 

(E-SplitRC) 


(q G {un,1in}) 


CS;q Ay:T.t) — >p (S, x ~ q Ay:T.t;x) 

(E-Fun’) 

CS; rc Ay:T.t) —p 
CS, x — rcCl) Ay:T.t;x) 

SCxi) = q Ay:T. t 
(q g {un.lin,rcCl)}) 


(E-FunRC) 


CS;xi x 2 ) —p CS ~ X!;[y - x 2 ]t) 
SCxi) = rcCn) Ay:T.t 
(n > landX = fV(Ay:T.t)) 
incr(S;X) = S' 


(E-App’) 


CS;xi x 2 ) —p CS' 


-c(n) 


xi;[y - 


x 2 ]t) 

(E-AppRC) 


incr(S;{x})= S' 


(S;inc(x)) —*p CS';1in <x,x>) 
(SCx) = rcCn) w) (n > 1) 
CS;decCx lXf )) ~p CS x;un Q) 


S = Si,x- rcCl) w,S 2 
S' = Si ,x Tin w,S 2 
(S;dec(x,x f )) — p (S';xf x) 


i_i 

Figure 1-17: Linear lambda calculus: Reference counting operational semantics 


exchange property, we are able to guarantee that certain values, those values 
allocated on the stack, are used in a first-in/last-out order. 

To formalize this idea, we organize the store into two parts: a stack, which 
is a sequence of locations that can be accessed on one end (the “top”) and 
a heap, which is like the store described in previous sections of this chap¬ 
ter. Pairs, functions and other objects introduced with unrestricted or linear 
qualifiers are allocated on the heap as before. And as before, when a linear 
pair or function is used, it is deallocated. Also, we allow programmers to allo¬ 
cate simple data structures on the stack. Without the exchange property, an 
ordered object can only be used when it is at the top of the stack. When this 
happens, the ordered object is popped off the top of the stack. 
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Syntax 

T ::= typing contexts: 

... as before 

r, x: rc (n) P rc(n) context 


Store Typing 


\- S : Ti o l 2 Ti i- rc w : rc P 
i- S,x — rc(n) w : r 2 ,x: rc(n) P 


(T-NextrcS) 


Context Splitting 

r = Ti o r 2 


+■ 3 


(M-RC) 


T, x: rc(n)P = 

(Ti, x: rc(i)P) o (r 2 , x: rc(j)P) 

(when i or j is 0, the corresponding binding is 
removed from the context) 


Variable Typing 

un (ri,r 2 ) 

ri, x: rc(l)P, r 2 I- x : rc P 


(T-RCVar) 


i _i 

Figure 1-18: Linear lambda calculus: Reference counting run-time typing 


Syntax 

The overall structure and mechanics of the ordered type system are very 
similar to the linear type system developed in previous sections. Figure 1-19 
presents the syntax. One key change from our hnear type system is that we 
have introduced an exphcit sequencing operation 1 et x = ti i n t 2 that first 
evaluates the term ti, binds the result to x, and then continues with the eval¬ 
uation of tz- This sequencing construct gives programmers exphcit control 
over the order of evaluation of terms, which is crucial now that we are intro¬ 
ducing data that must be used in a particular order. Terms that normally can 
contain multiple nested subexpressions such as pair introduction and func¬ 
tion apphcation are syntactically restricted so that their primary subterms 
are variables and the order of evaluation is clear. 

The other main addition is a new qualifier ord that marks data allocated on 
the stack. We only allow pairs and values with base type to be stack-allocated; 
functions are allocated on the unordered heap. Therefore, we declare types 
ord Ti - T 2 and terms ord Ax:T.t to be syntactically ill-formed. 

Ordered assumptions are tracked in the type checking context T hke other 
assumptions. However, they are not subject to the exchange property. More¬ 
over, the order that they appear in r mirrors the order that they appear on 
the stack, with the rightmost position representing the stack’s top. 

Typing 

The first step in the development of the type system is to determine how 
assumptions will be used. As before, unrestricted assumptions can be used 
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Syntax 



qualifiers: 

ord 

ordered 

lin 

linear 

un 

unrestricted 


terms: 

X 

variable 

q b 

Boolean 

if t then t else t 

conditional 

q <x,y> 

pair 

split t as x,y in t 

split 

q Ax:T.t 

abstraction 


Figure 1-19: Ordered lambda calculus: Syntax 


xy 

let x = t in t 

Bool 
T*T 
T—T 

q P 

0 

T, x:T 


application 
sequencing 
pretypes: 
booleans 
pairs 
functions 
types: 
qualified pretype 
contexts: 
empty context 
i variable binding 


as often as the programmer likes but linear assumptions must be used ex¬ 
actly once along every control flow path. Ordered assumptions must be used 
exactly once along every control flow path,in the order in which they appear. 

As before, the context splitting operator (r = Tl o r 2 ) helps propagate as¬ 
sumptions properly, separating the context r into T| and r 2 . Some sequence 
of ordered assumptions taken from the left-hand side of r are placed in H 
and the remaining ordered assumptions are placed in T 2 . Otherwise, the split¬ 
ting operator works the same as before. In the typing rules, the context r 2 
is used by the first subexpression to be evaluated (since the top of the stack 
is at the right) and H is used by the second subexpression to be evaluated. 
Formally, we define the "=" relation in terms of two subsidiary relations: "= 1 ," 
which places ordered assumptions in Ti, and "= 2 ," which places ordered as¬ 
sumptions in r 2 . See Figure 1-20. 

The second step in the development of the type system is to determine the 
containment rules for ordered data structures. Previously, we saw that if an 
unrestricted object can contain a hnear object, a programmer can write func¬ 
tions that duphcate or discard hnear objects, thereby violating the central 
invariants of the system. A similar situation arises if linear or unrestricted 
objects can contain stack objects; in either case, the stack object might be 
used out of order, after it has been popped off the stack. The typing rules 
use the qualifier relation qi^q 2 , which specifies that ord^l in^un, to ensure 
such problems do not arise. 

The typing rules for the ordered lambda calculus appear in Figure 1-21. For 
the most part, the containment rules and context splitting rules encapsulate 
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Context Split 

| r = Ti o r 2 1 

r = 2 ii o r 2 

r = Ti o r 2 

(M-TOP) 

0 =1 0 O 0 

(M-Empty) 

T =i Ti oT 2 

(M-OrdI) 

T, x:ord P =i (Ti, x:ord P) °T 2 

T = 2 Ti o r 2 

(M-Ord2) 

T, x:ord P = 2 Ti ° (T 2 , x:ord P) 


r =1 fi ° r 2 
r = 2 ri o r 2 
r =1,2 Ti o r 2 

T, x:lin P =i , 2 (fi, x: 1 in P) o r 2 


(M-1to2) 

(M-LinA) 


_ r =i , 2 r t °r 2 _ 

r, x: 1 in P = li2 Ti o (r 2 , x: 1 in P) 


(M-LinB) 


_ r =1,2 h ° r 2 _ 

T, x:un P =1,2 ffi, x:un P) o (r 2 , x:un P) 

(M-UN) 


i _i 

Figure 1-20: Ordered lambda calculus: Context splitting 


the tricky elements of the type system. The rules for pairs illustrate how this 
is done. The rule for introducing pairs (T-OPair) splits the incoming context 
into two parts, Ti and T 2 ; any ordered assumptions in T 2 will represent data 
closer to the top of the stack than Ti. Therefore, if the pair (x) and its two 
components xi and x 2 are all allocated on the stack, then the pointer x will 
end up on top, x 2 next and xi on the bottom. The elimination rule for pairs 
(T-OSplit) is careful to maintain the proper ordering of the context. As above, 
the rule splits the context into Ti and T 2 , where T 2 , which represents data on 
top of the stack, is used in a computation ti that generates a pair. The context 
Ti, xi :Ti, x 2 :T 2 is used to check t 2 . Notice that if both components of the 
pair, xi and x 2 , were allocated on the stack when the pair was introduced, 
they reappear back in the context in the appropriate order. 

Consider the following function, taking a boolean and a pair allocated se¬ 
quentially at the top of the stack. The boolean is at the very top of the stack 
and the integer pair is next (the top is to the right). If the boolean is true, 
it leaves the components of the pair (two unrestricted integers) in the same 
order as given; otherwise, it swaps them. 

Ax:ord (ord (int * int) * bool), 
split x as p,b in 
if b then 
P 

else 

split p as i1,i2 in 
ord <i2,i1> 
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un ai,r 2 ) 
ri,x:T,r 2 hx : T 

Un(F) C 

r i— q b : q Bool 

r 2 i- ti : q Bool 
h i- t 2 : T Fi ht 3 :T 
Ti o r 2 i- i f ti then t 2 el se t3 : T 

Ti i- xi : Ti r 2 hx 2 : T 2 
q(Ti) q(T 2 ) 

Ti o r 2 i- q <xi ,x 2 > : q OT*T 2 ) 


EE5i] 

(T-OVar) 


Figure 1-21: Ordered lambda calculus: Typing 


r 2 i- ti : q (Ti*T 2 ) 
li, xi :Ti, x 2 :T 2 i- t 2 : T 
Ti o r 2 i- spl i t ti as xi , x 2 i n t 2 

q(D r, x:Ti i- t 2 : T 2 
T h q Ax:Ti .t 2 : q Ti-T 2 


(T-OSplit) 

(T-OAbs) 


Ti i- xi : q Tn-Ti 2 r 2 h- x 2 : Tn 
Fi ° r 2 I- xi x 2 : Ti 2 
r 2 i- ti : Ti 
Ti, x:Ti i- t 2 : T 2 
Fl o r 2 i- let x = ti in t 2 : T 2 


(T-OApp) 


(T-OLet) 


Operational Semantics 

To define the operational semantics for our new ordered type system, we will 
divide our previous stores into two parts, a heap H and a stack K. Both are 
just a list of bindings as stores were before (see Figure 1-22). We also define a 
couple of auxiliary functions. The first says what it means to add a binding to 
the store. This is straightforward: unrestricted and linear bindings are added 
to the heap and ordered bindings are added to the top of the stack. 

(H;K) ,x ~ ord w = (H;K,x — ord w) 

(H;K),x~1inw = (H,x ~ lin w;K) 

(H;K),x~ U nw = (H,x~unw;K) 

The second function specifies how to remove a binding from the store. 
Notice that ordered deallocation will only remove the object at the top of the 
stack. 

(H;K,x~ v)°~ d x = H;K 

(Hi,x - v,H 2 ;K) ~"x = Hi, H 2 ; K 

(H; K) ~ x = H; K 

With these simple changes, the evaluation rules from previous sections can 
be reused essentially unchanged. However, we do need to add the evaluation 
context for sequencing (i et x = E i n t) and its evaluation rule: 

CSjiet x = xi in t 2 ) — p (S;[x ~ xijti) 


(E-Let) 
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S ::= stores: I K ::= stack: 


H; K 

H ::= 

0 

H, x >— 1 it 
H, x un 

complete store 0 empty stack 

heap: K, x-^ordw stack binding 

empty heap 
i w linear heap binding 

w unrestricted heap binding 

Figure 1-22: Ordered lambda calculus: Operational semantics 

1.4.1 

Exercise [Recommended, ★]: Write a program that demonstrates what can 
happen if the syntax of pair formation is changed to allow programmers to 
write nested subexpressions (i.e., we allow the term ord <ti ,t 2 > rather than 
the term o rd <x, y>). □ 

1.4.2 

Exercise [Recommended, ★★]: Demonstrate the problem with allowing or¬ 
dered functions (i.e., admitting the syntax ord Ax:Ti. t and ord Ti — T 2 ) by 
writing a well-typed program that uses ordered functions and gets stuck. □ 

1.4.3 

Exercise [*★★]: Modify the language so that programmers can use stack- 
allocated, ordered functions. There are many solutions to this problem, some 
more sophisticated than others. □ 

1.5 

Further Applications 


Memory management applications make good motivation for substructural 
type systems and provides a concrete framework for studying their proper¬ 
ties. However, substructural types systems, and their power to control the 
number and order of uses of data and operations, have found many appli¬ 
cations outside of this domain. In the following paragraphs, we informally 
discuss a few of them. 

Controlling Temporal Resources 

We have studied several ways that substructural type systems can be used to 
control physical resources such as memory and files. What about controlling 
the temporal resources? Amazingly, substructural type systems can play a 
role here as well: Careful crafting of a language with an affine type system, 
where values are used at most once, can ensure that computations execute in 
polynomial time. 
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To begin, we will allow our polynomial time language to contain affine 
booleans, pairs and (non-recursive) functions. In addition, to make things in¬ 
teresting, we will add affine lists to our language, which have constructors 
nil and cons and a special iterator to recurse over objects with list type. 
Such iterators have the following form. 

iter (stop => ti | x with y => t2> 

If ti has type T and t2 also has type T (under the assumption that x has type 
Ti and y has type Ti list), our iterator defines a function from Ti hsts to 
objects with type T. Operationally, the iterator does a case to see whether its 
input hst is nil or cons (hd, ti) and executes the corresponding branch. We 
can define the operation of iterators using two simple rules. 1 

iter (stop => ti | hd with rest => t2) nil ti (E-IterNil) 

iter (stop => ti | hdwith rest => t2) V2 —•£ v' 2 

—-7-—: —---7--(E-ITERCONS) 

iter (stop => ti | hd with rest => t2) cons(vi ,V2j p 

[hd - vi][rest - v' 2 \ti 

In the second rule, the iterator is invoked inductively on m 2 , giving the result 
v' 2 , which is used in term t 2 . The familar append function below illustrates 
the use of iterators. 

vai append : T list—T list—T list = 
iter ( 

stop => A(1 :T listj.l 

| hd with rest => A(1 :T list) .cons(hd, rest 1)) 

When applied to a hst 11 , append builds up a function that expects a second 
hst I2 and concatenates I2 to the end of li. Clearly, append is a polynomial 
time function, a linear-time one in fact, but it is straightforward to write ex¬ 
ponential time algorithms in the language as we have defined it so far. For 
instance: 

val double : T list^T list = 

iter (stop => nil | hd with rest => cons(hd,cons(hd, rest))) 
val exp : T list^T list = 

iter (stop => nil | hd with rest => double (cons(hd, rest))) 

1. Since we are not interested in memory management here, we have simplified our opera¬ 
tional semantics from previous parts of this chapter by deleting the explicit store and using 
substitution instead. The operational judgment has the form t— -pt' and, in general, is defined 
similarly to the operational systems in TAPL. 
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The key problem here is that it is trivial to write iterators like doubl e that 
increase the size of their arguments. After constructing one of these, we can 
use it as the inner loop of another, like exp, and cause an exponential blow¬ 
up in running time. But this is not the only problem. Higher-order functions 
make it even easier to construct exponential-time algorithms: 

val compose = 

A(fg: (T list-T list) * (T list-T list)). 

A(x:T list). 

split fg as f,g in f (g x) 

val junk : T 

val exp 2 : T list—T list—list = 
iter ( 

stop => A(1:T list) .cons(junk,l) 

| hd with rest => A(1 :T 1 ist).compose <rest,rest> 1) 

Fortunately, a substructural type system can be used to eliminate both 
problems by allowing us to define a class of non-size-increasing functions 
and by preventing the construction of troublesome higher-order functions, 
such as exp 2 . 

The first step is to demand that all user-defined objects have affine type. 
They can be used zero or one times, but not more. This restriction immedi¬ 
ately rules out programs such as exp 2 . System defined operators like cons 
can be used many times. 

The next step is to put mechanisms in place to prevent iterators from in¬ 
creasing the size of their inputs. This can be achieved by altering the cons 
constructor so that it can only be applied when it has access to a special 
resource with type R. 

operator cons : (R,T,T list) — T list 

There is no constructor for resources with type R so they cannot be generated 
out of thin air; we can only apply fcons as many times as we have resources. 
We also adapt the syntax for iterators as follows. 

iter (stop => ti | hd with tl and r => t 2 ) 

Inside the second clause of the iterator, we are only granted a single resource 
(r) with which to allocate data. Consequently, we can allocate at most one 
cons cell in t 2 . This provides us with the power to rebuild a list of the same 
size, but we cannot write a function such as doubl e that doubles the length 
of the list or exp that causes an exponential increase in size. To ensure that 
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a single resource from an outer scope does not percolate inside the iterator 
and get reused on each iteration of the loop, we require that iterators be 
closed, mirroring the containment rules for recursive functions defined in 
earlier sections of this chapter. 

Although restricted to polynomial time, our language permits us to write 
many useful functions in a convenient fashion. For instance, we can still write 
append much like we did before. The resource we acquire from destructing 
the list during iteration can be used to rebuild the list later. 

vai append : T list — T list — T list = 
iter ( 

stop => A(i :T Fist). I 

| hd with rest and r => A(1:T list). cons(r, hd, rest 1)) 

We can also write double if our input list comes with appropriate credits, 
in the form of unused resources. 

vai double : (T*R) list - T list = 
iter ( 

stop => nil 

| hd with rest and rl => 

split hd as x,r2 in cons(rl,hd,cons(r2,hd,rest))) 

Fortunately, we will never be able to write exp, unless, of course, we are 
given an exponential number of credits in the size of the input list. In that 
case, our function exp would still only run in linear time with respect to our 
overall input (list and resources included). 

The proof that all (first-order) functions we can define in this language run 
in polynomial time uses some substantial domain theory that lies outside 
the scope of this book. However, the avid reader should see Section 1.6 for 
references to the literature where these proofs can be found. 

Compiler Optimizations 

Many compiler optimizations are enabled when we know that there will be at 
most one use or at least one use of a function, expression or data structure. 
If there is at most one use of an object then we say that object has affine 
type. If there is at least one use then we say the object has relevant (or strict) 
type. The following sorts of optimizations employ usage information directly; 
several of them have been implemented in the Glasgow Haskell Compiler. 

• Floating in bindings. Consider the expression 1 et x = e i n (Ay... . x . ..). 

Is it a good idea to float the binding inside the lambda and create the new 
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expression Ay. 1 et x = e i n (...x...)? The answer depends in part on 
how many times the resulting function is used. If it is used at most once, 
the optimization might be a good one: we may avoid computing e and will 
never compute it more than once. 

• Inlining expressions. In the example above, if we have the further informa¬ 
tion that x itself is used at most once inside the body of the function, then 
we might want to substitute the expression e for x. This may give rise to 
further local optimizations at the site where e is used. Moreover, if it turns 
out that e is used zero times (as opposed to one time) we will have saved 
ourselves the trouble of computing it. 

• Thunk update avoidance. In lazy functional languages such as Haskell, 
evaluation of function parameters is delayed until the parameter is ac¬ 
tually used in the function body. In order to avoid recomputing the value 
of the parameter each time it is used, implementers make each parameter 
a thunk— a reference that may either hold the computation that needs to 
be run or the value itself. The first time the thunk is used, the computation 
will be run and will produce the necessary result. In general, this result is 
stored back in the thunk for all future uses of the parameter. However, if 
the compiler can determine that the data structure is used as most once, 
this thunk update can be avoided. 

• Eagerness. If we can tell that a Haskell expression is used at least once, 
then we can evaluate it right away and avoid creating a thunk altogether. 

The optimizations described above maybe implemented in two phases. The 
first phase is a program analysis that may be implemented as affine and/or 
relevant type inference. After the analysis phase, the compiler uses the infor¬ 
mation to transform programs. Formulating compiler optimizations as type 
inference followed by type-directed translation has a number of advantages 
over other techniques. First, the language of types can be used to communi¬ 
cate optimization information across modular boundaries. This can facilitate 
the process of scaling intra-procedural optimizations to inter-procedural op¬ 
timizations. Second, the type information derived in one optimization pass 
can be maintained and propagated to future optimization passes or into the 
back end of the compiler where it can be used to generate Typed Assembly 
Language or Proof-Carrying Code, as discussed in Chapters 4 and 5. 

1.6 Notes 

Substructural logics are very old, dating back to at least Orlov (1928), who ax- 
iomatized the implicational fragment of relevant logic. Somewhat later, Moh 
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(1950) and Church (1951) provided alternative axiomatizations of the rele¬ 
vant logic now known as R. In the same time period, Church was developing 
his theory of the lambda calculus at Princeton University, and his A I calculus 
(1941), which disallowed abstraction over variables that did not appear free 
in the body of the term, was the first substructural lambda calculus. Lambek 
(1958) introduced the first “ordered logic,” and used it to reason about natu¬ 
ral language sentence structure. More recently, Girard (1987) developed linear 
logic, which gives control over both contraction and weakening, and yet pro¬ 
vides the full power of intuitionistic logic through the unrestricted modality 
“!”. O’Hearn and Pym (1999) show that the logic of bunched implications pro¬ 
vides another way to recapture the power of intuitionistic logic while giving 
control over the structural rules. 

For a comprehensive account of the history of substructural logics, please 
see Dosen (1993), who is credited with coining the phrase “substructural 
logic,” or Restall (2005). Restall’s textbook on substructural logics (2000) pro¬ 
vides good starting point to those looking to study the technical details of 
either the proof theory or model theory for these logics. 

Reynolds pioneered the study of substructural type systems for program¬ 
ming languages with his development of syntactic control of interference 
(1978; 1989), which prevents two references from being bound to the same 
variable and thereby facilitates reasoning about Algol programs. Later, Gi¬ 
rard’s development of linear logic inspired many researchers to develop func¬ 
tional languages with Unear types. One of the main applications of these new 
type systems was to control effects and enable in-place update of arrays in 
pure functional languages. 

Lafont (1988) was the one of the first to study programming languages 
with linear types, developing a linear abstract machine. He was soon followed 
by many other researchers, including Baker (1992) who informally showed 
how to compile Lisp into a linear assembly language in which all allocation, 
deallocation and pointer manipulation is completely explicit, yet safe. An¬ 
other influential piece of work is due to Chirimar, Gunter, and Riecke (1996) 
who developed an interpretation of linear logic based on reference count¬ 
ing. The reference counting scheme described here is directly inspired by the 
work of Chirimar et al., but the technical setup is slightly different; we have 
explicit operations to increment and decrement reference counts whereas in¬ 
crementing and decrementing counts in Chirimar's system is done implicitly. 
Stephanie Weirich suggested the invariant for proving our reference count¬ 
ing system sound. Turner and Wadler (1999) summarize two computational 
interpretations that arise directly through the Curry-Howard isomorphism 
from Girard’s Unear logic. They differ from the account given in this chapter 
as neither account has both shared, usable data structures and deallocation. 
Unfortunately, these two features together appear incompatible with a type 
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system derived directly from linear logic and its single unrestricted modality. 

The development of practical linear type systems with two classes of type, 
one Unear and one unrestricted, began with Wadler’s work (1990) in the early 
nineties. The presentation given in this chapter is derived from Wadler's work 
and is also inspired by work from Wansbrough and Peyton Jones (1999) and 
Walker and Watkins (2001). Wansbrough and Peyton Jones included qualifier 
subtyping and bounded parametric polymorphism in their system in addition 
to many of the features described here. Walker and Watkins added reference 
counting features to a language with Unear types and also memory regions. 
The idea of formulating the system with a generic context splitting operator 
was taken from Cervesato and Pfenning’s presentation of Linear LF (2002). 

The algorithmic type system described in section 1-5 solves what is com¬ 
monly known in the linear logic programming and theorem proving literature, 
as the resource management problem. Many of the ideas for the current pre¬ 
sentation came from work by Cervesato, Hodas, and Pfenning (2000), who 
solve the more general problem that arises when linear logic’s additive con¬ 
nectives are considered. Hofmann takes a related approach when solving the 
type inference problem for a linearly-typed functional language (1997a). 

The ordered type system developed here is derived from Polakow and Pfen¬ 
ning’s ordered logic (1999), in the same way that the practical linear type 
systems mentioned above emerged from linear logic. It was also inspired by 
the ordered lambda calculus of Petersen, Harper, Crary, and Pfenning (2003), 
though there are some technical differences. Ahmed and Walker (2003) and 
Ahmed, Jia, and Walker (2003) use an ordered, modal logic to specify memory 
invariants and have integrated the logical specifications into a low-level typed 
language. Igarashi and Kobayashi (2002) have used ordered types to explore 
the more general problem of resource usage analysis. In addition, they have 
developed effective type inference algorithms for their type systems. 

Recently, O’Hearn (2003) has proposed bunched typing, a new form of sub- 
structural typing, to control interference between mutable variables, gener¬ 
ating Reynolds’s earlier work on syntactic control of interference. These 
bunched types were derived from earlier work by O’Hearn and Pym (1999) 
on bunched logic. Together, Reynolds, Ishtiaq, and O’Hearn (Reynolds, 2000; 
Ishtiaq and O'Hearn, 2001) have used bunched logic to develop a system for 
verifying programs that expUcitly aUocate and deallocate data. 

Analysis and reasoning about the time and space complexity of programs 
has always been an important part of computer science. However, the use 
of programming language technology, and type systems in particular, to au¬ 
tomatically constrain the complexity of programs is somewhat more recent. 
For instance, Bellantoni and Cook (1992) and Leivant (1993) developed pred¬ 
icative systems that control the use and complexity of recursive functions. 
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It is possible to write all, and only, the polynomial-time functions in their 
system. However, it is not generally possible to compose functions and there¬ 
fore many “obviously” polynomial-time algorithms cannot be coded naturally 
in their system. Girard (1998), Hofm ann (2000; 1999), and Bellantoni, Niggl, 
and Schwichtenberg (2000) show how linear type systems can be used to al¬ 
leviate some of these difficulties. The material presented in this chapter is 
derived from Hofmann’s work. 

One of the most successful and extensive applications of substructural 
type systems in programming practice can be found in the Concurrent Clean 
programming language (Nocker, Smetsers, van Eekelen, and Plasmeijer, 1991). 
Clean is a commercially developed, pure functional programming language. It 
uses uniqueness types (Barendsen and Smetsers, 1993), which are a variant of 
hnear types, and strictness annotations (Nocker and Smetsers, 1993) to help 
support concurrency, I/O and in-place update of arrays. The implementation 
is fast and is fully supported by a wide range of program development tools 
including an Integrated Development Environment for project management 
and GUI hbraries, all developed in Clean itself. 

Substructural type systems have also found gainful employment in the in¬ 
termediate languages of the Glasgow Haskell Compiler. For instance, Turner, 
Wadler, and Mossin (1995) and Wansbrough and Peyton Jones (1999) showed 
how to use affine types and affine type inference to optimize programs as 
discussed earlier in this chapter. They also use extensive strictness analysis 
to avoid thunk creation. 

Recently, researchers have begun to investigate ways to combine substruc¬ 
tural type systems with dependent types and effect systems such as those 
described in Chapters 2 and 3. The combination of both dependent and sub¬ 
structural types provides a very powerful tool for enforcing safe memory 
management and more general resource-usage protocols. For instance, De- 
Line and Fahndrich developed Vault (2001; 2002), a programming language 
that uses static capabihties (Walker, Crary, and Morrisett, 2000) (a hybrid 
form of hnear types and effects) to enforce a variety of invariants in Microsoft 
Windows device drivers including locking protocols, memory management 
protocols and others. Cyclone (Jim et al., 2002; Grossman et al., 2002), a 
completely type-safe substitute for C, also uses hnear types and effects to 
grant programmers fine-grained control over memory allocation and deallo¬ 
cation. In each of these cases, the authors do not stick to the pure hnear types 
described here. Instead, they add coercions to the language to allow linearly- 
typed objects to be temporarily aliased in certain contexts, following a long 
hne of research on this topic (Wadler, 1990; Odersky, 1992; Kobayashi, 1999; 
Smith, Walker, and Morrisett, 2000; Aspinall and Hofmann, 2002; Foster, Ter- 
auchi, and Aiken, 2002; Aiken, Foster, Kodumal, and Terauchi, 2003). 




